Testing communication networks is very important to ensure reliability and quality of service. Packet blaster systems for doing this, such as shown in FIG. 1, are well known. These have traffic generators and traffic receivers for generating and receiving respectively very large numbers of data flows on multiple interfaces via network elements (NE) in order to test the ability of the system under test (SUT) to carry and manage large numbers of services in the specified manner. By flow is meant all the packets associated with a single customer's data, or multiple customers' data that has been grouped together and labelled with a common header or, more generally, all packets that have the same label in the section of header of interest. The usual outcome of this sort of testing is error-free transfer of each service from source to specified destination. In cases of congestion, this type of test solution can be used to prove that the correct prioritisation of traffic has occurred with the highest priority traffic being carried in preference to low-priority traffic flows.
Packet blaster systems connect at the edge of the SUT and are able to generate packet flows with a large selection of packet structures. These systems can be used to stress test the SUT by generating large numbers of flows and/or varying the bandwidth or rate of generation of each flow. In these test systems, all packet flows received are generated from an instance of the Test Solution. The received flows are used to verify the end-to-end Quality-of-Service (QoS) parameters being achieved under multiple loading situations. Whilst this is valuable, a problem is that if the QoS is not as expected, depending on the source of the issue e.g. problems that occur at the centre of the SUT, packet blaster systems cannot debug or identify the cause. In addition, they are unable to test a new or unsupported packet structure until the packet structure of interest has been implemented as an enhancement to the Test Solution.
Packet blaster systems are designed to replicate and/or emulate equipment positioned at the edge of the telecommunications network for the purpose of testing the network elements. Network emulators are a class of test solution used to emulate networks with the objective of testing network elements to be deployed at the edge of the network, as shown in FIG. 2. These test solutions act as a live network replacing the whole network, i.e. they are designed to test the edge equipment connecting to the network, not the network. Network emulators can operate with multiple flows by receiving multiple signals, identifying the individual flows and re-grouping for retransmission to the end units each of which contains multiple data flows. While it is possible to alter the flows, the complete impact of the network is emulated rather than individual effects and/or intermediate points. These testers always terminate and regenerate all traffic flows in all inputs connected to them. While this enables control of the retransmission of flows, it is done by having to specify all aspects of the output. This is a significant limitation where the relative behaviour of packet flows is impacting the performance.
Another network test solution is the traditional transport tester, which is aimed at testing a single connection having only one transmitter and one receiver. Transport testers primarily offer the capability to fully stress test TDM Framing structure of the signal under test, as well as a limited capability to test packet flows embedded within that structure. Their primary function is the verification of the ability to achieve point-to-point transmission, i.e. the role of the Framing structure and TDM Transport Layer, as well as a limited capability in the packet domain for verifying point-to-point transfers. The principle approach of testing one signal is continued into the packet layer with these test solutions offering testing of a single or small number (<8) of packet flows embedded within the TDM structured signal. Limitations of such traditional testers are, however, their inability to operate with large numbers of packet data flows and to analyse large numbers of packet-flows embedded in a TDM signal, as well as their lack of scalability for analysing multiple signals in parallel.
Another solution adopted when operating with multiple packet flows allows control of the retransmission of each of the flows accurately. However, all the input characteristics are removed by demultiplexing the signal completely. In addition, this solution cannot replicate precise network characteristics of real networks and it cannot handle large numbers of packet flows, as the core engine needs to be replicated for each flow to be adjusted. Furthermore, it is not possible to select not to change any aspect of some packet flows and only adjust those to be tested. All characteristics are impacted as they pass through the tester. It is not possible to change one parameter without impacting other characteristics of the flow.
Another problem with most existing network test systems is that their presence has an impact on the performance of the network that they are trying to measure, or interferes in some way with normal network operation. This means that the robustness of the whole system cannot be assessed. Also, most are positioned in the SUT in place of existing network equipment. When a problem is recognised at the end of a transmission path, the network equipment that recognises the problem needs to signal back to the equipment at the source of the transmission path that a problem has occurred to enable it to invoke its protection process. If this equipment has been replaced with a piece of test instrumentation, then this can be problematic. To address this problem, the test instrument has to be able to recognise and respond to the alarm message to invoke the protection process, requiring the test instrumentation to be programmed with proprietary commands for each manufacturer of network equipment.